Josh On Design

As I write this I am speeding over the Atlantic at around 500 miles per hour towards a two week business trip. The goal is to work out further details of the JavaFX tools and plan our schedule for next year. (And no I'm not going to give you any details. That's not what this post is about :). As I'm finishing up emails and pondering my two weeks of meetings I'm struck by a question: How did we get here?

Okay, I don't mean the existential question of existence. Instead, how did Java, more specifically client Java, get here? How did we end up with the new version of the JRE, and JavaFX, and great new stuff in NetBeans 6? I'm feeling a renaissance of client Java welling up, but there were some dark days in the past. In fact, I wrote about them prodigiously.

I started my Java.net blog almost two years before I came to work for Sun and I've often be critical of client-side Java; but only because I love it and want to see improvements. Two of my blog entries come to mind, in particular. The first, Swing has failed. What can we do?, was written in late 2003 and a second, The Reponse to Why Don't you Ship Swing Apps, in mid 2005.

Looking at the stats these two blog posts are among my most heavily read blog entries with about 10 times the average for most of my posts. (The number one spot, oddly enough, goes to Swing Hack 4: The universal right click, which I suspect is boosted by the long tail of Google).

It has been over two years since I wrote that second post (and will hit 3 by the time of JavaOne), so I thought I'd take a moment to reflect on what were the problems I documented back then and what we've done to fix them. It's really quite extraordinary. Everything on my list has been addressed! Now, I'm not saying that I'm the reason they are all fixed, but it is nice to see that we were all thinking about the same things. Let's take a look at what we've done. (the following list is condensed from both blog entries).

Why Swing apps suck

Swing apps are slow to build and Swing layout managers suck. Well, these complaints basically boil down to the lack of good visual tools, now addressed by the NetBeans form builder and greatly improved in version 6 with binding and the app framework. Check.

Swing apps are hard to maintain. This complaint is really that we need some sort of a framework for Swing applications. We now have such a beast, creatively named the Swing Application Framework. Check.

Swing is too powerful. I was really complaining about not having higher level components. A lot of this is solved with the components from SwingLabs, though we still have some work to do. Half check.

No native features. The problems with JNI have a long and sordid history but JNA has made great strides here, as have new features in Java 6 (like the java.awt.Desktop API and SystemTray) as well as the many things the Apple Java team has done to improve native fidelity. You can even use JNA to create real shaped Windows. At least 3/4 of a Check.

Swing apps have a bad history Well, still working on this one. We've made headway with really cool JavaOne demos (Extreme GUI makeover, Aerith, Iris) but we've got more to do. We really need the community help, though. What do you need from us to make great looking apps? 1/2 check.

Make something better than Metal and Visual Appearance (ie, don't be ugly). I'd say that Nimbus really fixes this one. Oh, and of course the many fixes we did to the Windows Look and Feel. Check x 2!

Better Javadocs & Examples, the look of the JavaDocs haven't changed, though the content has. That's something I hope to address soon. I know we have some great new examples coming out both as part of NetBeans and in another form you'll hear about later. 1/2 check.

Deployment: Java Web Start, Java Auto-Install Toolkit, Smaller JRE Download: Update N is designed to completely solve these problems. Check.

Performance and Memory Usage. Tons of work went into Java 6 to improve performance and reduce memory usage. Update N will include more improvements specifically targeted at startup time. We've definitely got this one down. Super Check.

All the pieces

So here's my real point. When Java 6 update N ships (when the N has been replaced with an actual number), we will have completed a series of changes designed to revolutionize desktop Java programming. While it may appear that all of this has happened in the last six months since the JavaFx announcements last May, that is not the case. This is really many different pieces in development for quite a while, some of them for years. (we've wanted to do the Java Kernel idea for a *long* time).

So the pieces are coming together. Better runtime. Better tools. Better deployment. (and I even hear better jobs). It's a great time to be a client Java developer. So what are you going to build?